How would it be possible for a PyPI range to use semver?
Also this code is too complicated for me to understand as is the same code above... can you find a way to decompose this in something simpler? Also it is duplicated almost exactly with the code above... so creating a function would make sense to avoid duplicated code.

ex: GHSA-2ghc-6v89-pw9j.json
https://osv.dev/vulnerability/GHSA-2ghc-6v89-pw9j

@ziadhany Thanks ... so in https://osv.dev/vulnerability/GHSA-2ghc-6v89-pw9j I see three different affected packages:

• npm/body-parser-xml which would become the purl pkg:npm/body-parser-xml and is reported as SEMVER versioning which would become the npm vers scheme on our side. This is found at https://www.npmjs.com/package/body-parser-xml

• NuGet/body-parser-xml-nuget which would become the purl pkg:nuget/body-parser-xml-nuget and is reported as ECOSYSTEM versioning and would become the nuget vers scheme on our side... BUT this does NOT exist as a nuget package at all. https://www.nuget.org/packages?q=body-parser-xml ... not even close

• PyPI/body-parser-xml-pip which would become the purl pkg:nuget/body-parser-xml-pip and is reported as ECOSYSTEM versioning and would become the pypi vers scheme on our side. BUT this does NOT exist as a pypi package at all: https://pypi.org/search/?q=body-parser-xml

So what to make of this? OSV and GitHub data are likely not really reviewed after all. That's not the first time I see junk ghost records like this that are supposedly reviewed.

In anycase this are not a Pypi package... but it is going to be hard to figure this out ... at least not at import time.
I note that this is not seen at all in https://github.com/pypa/advisory-database
So practically:

• I entered Add improver to validate that collected purl are real. #644 to add improvers to validate purls
• short term we could flag these with lower confidence but I am not sure we have enough at import time
• so we can import these ... each should use their own specific vers scheme though and PyPI is NOT semver alright

There is not much harm done to import non-existing purl BTW because these would never be found in the wild.

Are you sure this may not be CVSS:3.1 and cvssv3.1_vector instead? https://github.com/nexB/vulnerablecode/blob/47f6ae62d919fff5094b960c1f56bc0c6b8b4be3/vulnerabilities/severity_systems.py#L83

No, I'm not sure.
but have a look at osv-schema:
https://ossf.github.io/osv-schema/#severitytype-field
Severity Type: CVSS_V3
Score Description : A CVSS vector string ...

ex GHSA-xc3p-ff3m-f46v.json:
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N"

What about this? Spelling out whole words is fine

BTW, why do you need a raw_id there?

just for logs (to track the root cause of errors and fix them easily)

Same comment as above...

What about something like this instead?

    affected_versions = affected_pkg.get("versions")
    if affected_versions:
        try:
            return PypiVersionRange(affected_versions)

What could be the exceptions raised here?

I think InvalidVersionRange

Always prefer to create a named variable in such case:

Try to give a name early to avoid multiple lookups and carrying around less common names:

You replace the whole function body by:

Also what is severity here? a list since it afterward assigned to severities?
how does it apply to the whole list of references and not just to a single one?

Do you have an example of data?

reference field (url) and a severity field are separated from each other in osv-schema. I think we can make use of ADVISORY type field in reference and assign the severities to it but What if there is two ADVISORY ?

ex: GHSA-2qx8-589j-gcpx

{
  "database_specific": {
    "severity": "MODERATE",
    "github_reviewed": true,
    "cwe_ids": []
  },
"references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2011-1950"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/67695"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-2qx8-589j-gcpx"
    },
...
  ]

}

ex: GHSA-2gwj-7jmv-h26r

{
  "database_specific": {
       "severity": "CRITICAL",
  }
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"
    }],
"references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28346"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django/django/commit/93cae5cb2f9a4ef1514cf1a41f714fef08005200"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/04/msg00013.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/django/django"
    }
  ]
  ]
...}

Any suggestions?

Same nit as above: you are doing two lookups in package: here and below on line 184.
You should collect ecosystem and name in variables once instead

Should this be outside of the loop rather?

You should put error checks first at the top and invert this if/else block and if there no "type" you should return right way.
This will make the code simpler and remove one indentation level

What about this instead? It may be easier to read than a filter with a lambda?

    for event in fixed_range.get("events") or []:
        fixed = event.get("fixed")
        if fixed:
            yield fixed

I am not sure the date is important enough to warrant logging

get_severity --> get_severities since there are more than one

IMHO you should rather yield as you go instead of accumulating in a list. The code will be leaner then

This is no longer needed since the code below (for sever_list in raw_data.get("severity") or []: handles all the possible cases:

It is always best to return early if there is nothing left to do.
This way you can de-indent the code that comes after

Following from above, this becomes not needed:

affected may not be a list, so to be safe, I would use this:

Use a raw_id variable defined above